home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 823 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.4 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: kanze@gabi-soft.fr (J. Kanze)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Enumerated type converted to pointer? Legal?
  5. Date: 22 Mar 1996 09:28:31 PST
  6. Organization: GABI Software, Sarl.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <KANZE.96Mar22115626@gabi.gabi-soft.fr>
  9. References: <4hobji$mco@netlab.cs.rpi.edu>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 22 Mar 1996 10:56:26 GMT
  12. In-reply-to: bstowers@pobox.com's message of 8 Mar 1996 04:04:02 -0000
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMVLjU0y4NqrwXLNJAQE5AwIAmi/eEiDCqVP3QxdQ1LJu7g9gXVmYMrbQ
  15.     a+jjw8OWQWut3vEm9I5YCdVa5b+ib8oQIKFpMwloWO0BIrH8+ZA8mA==
  16.     =Tpse
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article <4hobji$mco@netlab.cs.rpi.edu> bstowers@pobox.com (Brad
  20. Stowers) writes:
  21.  
  22.     [I've stripped all but comp.std.c++ out of the newsgroups line.  In
  23.     general, it is very awkward for the moderators if you cross-post to
  24.     several moderated groups, and comp.std.c++ seemed the most
  25.     appropriate.]
  26.  
  27. |> #include <stdio.h>
  28.  
  29. |> typedef enum { mdType1, mdType2, mdType3 } myType;
  30.  
  31. |> void FooBar(int x,
  32. |>             int* y,
  33. |>             myType type = mdType1)
  34. |> {
  35. |>   printf("x=%i\ny=%p\ntype=%type\n", x, y, type);
  36.                                            ^
  37.  
  38. Just a warning: this is undefined behavior, although it will work on a
  39. lot of machines.  You must cast any parameter corresponding to a `%p' to
  40. void* (if it isn't void* already).
  41.  
  42. Also: what is %type?
  43.  
  44. (The above sound like two very good reasons for switching to iostream to
  45. me.) 
  46.  
  47. |> }
  48.  
  49. |> main()
  50. |> {
  51. |>   int x = 10;
  52. |>   int* y = &x;
  53. |>   FooBar(x, y, mdType2);
  54. |>   FooBar(x, mdType1);
  55. |> }
  56.  
  57. |> ------------------EOF------------------------------
  58.  
  59. |> Compile and run the above program.  Is it just me, or should the last line
  60. |> of the main() function ( FooBar(x, mdType1); ) have caused a type mismatch
  61. |> error?
  62.  
  63. Definitly.
  64.  
  65. |> I think I know why it didn't:  mdType1 evaluates to an integer with
  66. |> a value of 0, which is a valid value to pass as a pointer.  In support of
  67. |> this theory, the line:
  68.  
  69. |>   FooBar(x, mdType2);
  70.  
  71. |> will not compile, but rather generates the expected type mismatch error.
  72. |> Obviously, the work-around is simple:
  73.  
  74. |>   typedef enum { mdType1 = 1, mdType2, mdType3 } myType;
  75.  
  76. |> While this will solve the problem, I really think that it is the compiler's
  77. |> job to see that mdType1 does not evaluate to the proper type no matter what
  78. |> it's internal representation might be.
  79.  
  80. Correct.  There is nothing in the standard that allows converting an
  81. enum to a pointer, irrespective of the numerical value of the enum.
  82.  
  83. |> I have verified that this happens on both Borland and Symantec compilers.
  84. |> Can anyone verify it on Watcom and Microsoft for me?
  85.  
  86. No.  On a Sun, however, g++ (2.7.2) gives the correct error message.
  87. Sun CC (4.1) has the same error as Borland and Symantec.
  88.  
  89. The error may be historically conditioned.  As I interpret the C
  90. standard, an enumerated constant has type int, and a constant integral
  91. expression which evalutates to 0 is a null pointer.  Even in the ARM,
  92. however, ``An enumeration is a distinct integral type.''
  93.  
  94. (In fact, the question is less clear that the above would make it
  95. appear.  While the C standard definitly says that an enumerator has type
  96. int, it also implies that the enum statement itself defines a new
  97. distinct type, ``compatible with an integer type.''  And while in the
  98. absense of a definite statement to the contrary in the ARM, and the
  99. insistence that the enumeration is a distinct type, I think that the
  100. intent is clear that the enumerator should have the same type as the
  101. enumeration, rather than int, there are no explicit words to this
  102. effect.)
  103.  
  104. This is all passe, however.  From the Jan., 1996 draft standard: ``The
  105. type of an enumerator is its enumeration.''  You cannot get any clearer
  106. than that.
  107. -- 
  108. James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
  109. GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
  110. Conseils en informatique industrielle --
  111.                             -- Beratung in industrieller Datenverarbeitung
  112. ---
  113. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  114.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  115.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  116.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  117.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  118. ]
  119.